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(57) Abstract: A system for authorising smart cards via the Internet is provided, comprising a plurality of user stations (1-1- 1-n) 
connected to a server (3) via the Internet (5). Each of the user stations (l-l;l-n) is attached to a card reader (7-l;7-n) suitable for 
reading data and accessing processing modules on smart cards (8-1 -8-m). When a new card is to be issued, initially the server (3) 
generates and stores a task identifier as a task record (15) on a database (10) connected to the server (3). The task identifier is also 
dispatched to a user station (l-l;l-n). A subsequent data submission by the user station (l-l;l-n) is then required to include signed 
data incorporating authorisation data and the received task identifier. When all the data required for authorisation of a smart card 
(8-l;8-m) has been received, the server (3) checks the signed data to confirm each data submission comprises data incorporating a 
correct task identifier utilised for the current authorisation procedure. 
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MULTI-STAGE AUTHORISATION SYSTEM 

The present invention concerns secure multi-stage 
authorisation systems. In particular, the present 
invention concerns a secure multi-stage authorisation 
system in which data is transmitted over a public network 
such as the Internet, 

The Internet provides a convenient means by which 
data stored on remote computers may be accessed. 
However r the public nature of the Internet means that 
websites accessible by the Internet are exposed and 
difficult to secure. Where a website contains sensitive 
data it is therefore essential to provide additional 
security to prevent unauthorised access. 

One means by which access to a website may be made 
secure is by use of cryptographically enabled smart 
cards. Specif ically, private/public key encryption 
modules may be provided by a smart card or other portable 
data processing device. The public /private key 

encryption modules can then be used to 1 sign ' and encrypt 
data which is transmitted over the potentially insecure 
connection. 

In order for smart cards to prevent unauthorised 
access to websites , it is necessary to ensure that smart 
cards for accessing a remote computer are only issued to 
authorised individuals. For this purpose , smart card 
issuance and authorisation systems generally require a 
number of multiple operations (e.g. collect data, 
authorise, witness, request certificate etc) to ensure 
that cards are not erroneously or fraudulently issued. 

Although a multiple stage authorisation process can 
ensure a card is not inappropriately issued, where multi- 
stage operations are themselves effected across a public 
network such as the Internet it is possible that the 
authorisation operations themselves may be intercepted 
and later duplicated to obtain fraudulent authorisation. 



WO 02/084611 



PCT/GB02/01684 



2 

There is therefore a need for a multistage 
authorisation system in which data may be transferred via 
a public network but which prevents fraudulent 
authorisation from being obtained. 
5 In accordance with one aspect of the present 

invention there is provided a data validation process 
comprising the steps of: 

storing a task identifier on a server and 
dispatching a copy of said task identifier to a remote 
10 station; 

at said remote station, for a plurality of items of 
transaction data, combining said task identifier with a 
said item of transaction data and signing said combined 
data utilising an encryption method? 
15 dispatching said signed data to said server together 

with identification data; and 

verifying the validity of the received signed data 
at said server, utilizing an encryption method selected 
on the basis of said identification data received with 
20 signed data to determine if said signed data was 

generated from combined data incorporating said task 
identifier. 

Further aspects and embodiments of the present 
invention will become apparent with reference to the 
25 following description and accompanying drawings in which: 

Figure 1 is a schematic block diagram of a computer 
network in accordance with a first embodiment of the 
present invention ; 

Figure 2 is a schematic block diagram of task 
30 records and user records stored within a database of the 

computer network of Figure 1 ; 

Figure 3 is a schematic block diagram of a smart 
card of Figure 1; 

Figure 4 is a flow diagram of a card log in 
35 procedure; 
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Figure 5 is a flow diagram of the processing of data 
to effect an individual stage of a multi-stage 
authorisation process; 

Figures 6A, 6B and 6C are schematic block diagrams 
illustrating the generation of data for dispatch across 
the public network of Figure 1 ; 

Figure 7 is a flow diagram of the processing of an 
issuing program on the server of the computer network of 
Figure 1 ; 

Figure 8 is a flow diagram of the processing of the 
issuing program on the server to determine whether a 
stage of multi-stage authorisation process is authorised; 

Figure 9 is a flow diagram of the processing of a 
user station in accordance with a second embodiment of 
the present invention; and 

Figure 10 is a .flow diagram of the processing of a 
server in accordance with a second embodiment of the 
present invention. 

First Embodiment 

Figure 1 is a schematic block diagram of a computer 
network in accordance with a first embodiment of the 
present invention. The computer network comprises a 
plurality of user stations 1-1- 1-n that are all connected 
to a server 3 via the Internet 5 . Individual smart card 
readers 7-1-7-n connected to each of the user stations 
1-1- 1-n are provided enabling communication between a 
number of smart cards 8-1-8-m and the respective user 
stations 1-1-1-n. In this embodiment the smart cards 8- 
1-8-m each comprise cryptographically enabled smart cards 
for encrypting data utilizing conventional public /private 
key encryption technology . 

The server 3 r in addition to being connected to the 
Internet 5 is also connected to a database 10 which is 
arranged to store task records 15 and user records 17. 
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In the memories of each of the user stations 1-1-1-n is 
stored a card interface module 20 and a browser program 
22. Stored within the memory of the server 3 is an 
issuing program 24. 
5 In accordance with this embodiment of the present 

invention, the card interface module 20 , browser program 
22 and issuing program 24 interact together with 
encryption modules provided on the smart cards 8-1-8-m 
to enable data for effecting an update of user records 

10 17 to be transmitted via the Internet 5 in a number of 

stages whilst preventing updates from occurring if data 
transmitted via the Internet 5 is intercepted and 
modified or reused. 

Specif ically, the present embodiment will be 

15 described with reference to the process of updating user 

records 17 to effect issuing and authorising of new smart 
cards 8 for later access to the server 3 and database 10. 
It will be appreciated that as issuance and authorisation 
of a smart card normally enables the holder of the smart 

2 0 card to access data, it is imperative that such a process 

is conducted in a secure manner. Although the present 
embodiment will be described in terms of the issuance and 
authorisation of a smart card 8, it will be appreciated 
that the present invention is applicable to any process 

25 requiring the secure transmission of multiple sets of 

data via a public and therefore potentially insecure 
network . 

In use/ in this embodiment, the integrity of 
authorisation data is ensured in a number of ways. 

30 Initially, when a connection is first made between a user 

station l-l;l-n and the server 3 a session identifier is 
generated and stored within the database 10. A copy of 
the session identifier is then dispatched and stored in 
the memory of the user station l-l;l-n making the 

35 connection. All subsequent transmissions between the 



WO 02/084611 



PCT/GB02/01684 



5 

user station l~l;l-n and the server 3 in the case of a 
session are then made to include this session identifier. 
Thus only a. user station 1— l;l-n having a stored session 
identifier can submit data and any data resubmitted from 
another session can be detected. 

Additionally , whenever a new task is initiated by 
a user station 1-1 ; 1-n, for example the processing 
required to authorise a new smart card .8, a unique task 
identifier is transmitted by the server 3 for inclusion 
in the next submission to be made in the session. These 
unique task identifiers are stored together with session 
identifiers as task records 15 within the database 10. 
By requiring the inclusion of the appropriate task 
identifier in each data submission effecting a stage in 
a task, attempted resubmissions of data from other tasks 
within a session can be detected. 

Finally, whenever data is submitted, the data 
including both the session identifier and task identifier 
is required to be "signed" by the user submitting the 
data by generating message hash data from the complete 
data submission including both the session identifier and 
task identifier. This message hash data is then 
encrypted, utilising an encryption module provided on the 
user's smart card 8. Thus in this way the format and 
content of each data submission and the identity of the 
smart card 8 utilised to submit the data can be 
confirmed. 

When the issuing program 2 4 of the server 3 
determines that data for all stages of a task, for 
example a multiple stage authorisation process, have been 
received from a user station 1-1; 1-n the received data 
is checked to ensure that the session identifiers and 
task identifiers included within the received data 
correspond to a set of session identifiers and task 
identifiers stored as task records 15. The issuing 
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program 2 4 then confirms that decoding the message hash 
data confirms that the submission has not been altered 
and confirms the identity of the smart card 8 utilised 
to submit the data. If the data is determined to be 
5 unaltered, the issuing program 24 then determines whether 

the user as represented by data on the previously issued 
smart card 8-1, 8-n, utilised to generate the message hash 
has authority to authorise the issuance of a card. If 
this is the case, the received data is then processed to 

10 generate a new user record 17 thereby activating a new 

smart card 8 for access to the server 3. 

By providing a system in which all data submissions 
made by a user station 1-1 to the server 3 are made to 
incorporate a session identifier and task identifier , a 

15 means is provided to detect the re-submission of any data 

involved from an earlier authorisation procedure. Thus 
in this way, every data submission made by a user station 
l-l;l-n to the server 3 is uniquely identified and locked 
into the task and the session from which it originated. 

2 0 If for any reason a data submission is intercepted as it 

is transmitted via the Internet 5, the re-use of such 
data can be detected and unauthorised issuance prevented. 
The complete authorisation process can therefore be 
effected in a secure manner even if individual data 

25 submissions happen to be intercepted. 

Prior to describing in detail the processing of the 
browser program 22 and the issuing program 24, data 
structures for the task records 15 and user records 17 
and the programs and data stored on a smart card 8 will 

30 first be described in detail with reference to Figures 

2. 

Figure 2 is a schematic block diagram of the content 
of database 10 containing task record 15 and user records 
17 . 

35 In this embodiment, each task record 15 comprises 
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a session identifier 32, a time stamp 33 and a task 
identifier 34. Whenever a user station l-l;l-n first 
accesses the server 3 via the Internet 5, a new task 
record 15 comprising a newly generated session identifier 
32, a time stamp 33 being the current time and a task 
identifier 34 is created and stored in the database 10. 
Subsequently, whenever further a new task is initiated 
by a user station 1-1 ; 1-n in the course of that session, 
additional task records 15 are generated and stored 
comprising the same session identifier 32, a new time 
stamp 33 and a task identifier 34 for the new task. As 
will be described in detail later when an authorisation 
procedure has been completed, the task records 15 are 
then utilised to confirm that data has in. fact been 
received from an authorised individual. 

In addition to the task records 15, in this 
embodiment a set of user records 17 are also stored 
within the database 10. In this embodiment, the 
individual user records -.1.7 each comprise card 
identification data 42 for identifying a smart card 8, 
public key data 44 for encrypting data and being part of 
a public /private key pair in which the private key data 
is stored on the smart card 8 identified by the card 
identification data 42; authorisation data 46 being data 
identifying the processes the user represented by the 
user record 17 is authorised to perform; and user details 
data 48 being data such as the name and address 
identifying individual to whom a smart card 8 identified 
by the card identification data 42 has been issued. 

As will be described in detail later in this 
embodiment the user records 17 are utilized to establish 
whether requests for issuing further smart cards 8 are 
valid. It will be appreciated that once a user record 
17 linking a smart card 8 with authorisation data 4 6 has 
been generated and stored within the database 10, this 
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database of authorised and issued smart cards could be 
utilized to restrict access to data stored elsewhere on 
the database 10, the server 3 or any other system. 

Figure 3 is a schematic block diagram of program 
5 modules and data stored on a smart card 8. In this 

embodiment each of the smart cards 8-l;8-m comprises a 
secure processing device that can process data 
transmitted from a user station 1-1; 1-n via a smart card 
reader 7-1; 1-n attached to that user station 1-1; 1-n, 

10 Each of the smart cards 8 in this embodiment is arranged 

to store card identification data 42 being data for 
identifying the smart card 8 and the authorised user of 
the smart card 8 to the server 3; a personal 
identification number 52 being a number to be entered by 

15 the authorised user of a smart card 8 to authorise access 

to the encryption processes provided by the smart card 
8; a login module 53 for controlling access to the 
encryption processes provided by the card 8, an 
encryption module 54 and public key 55 and private key 

20 data 56 for encrypting data; and an enabled/disabled flag 

58. 

By providing an encryption module 54 and public and 
private key data 55; 56 on the smart card a. means is 
provided to enable the user of a smart card 8 to sign 
2 5 data for transmission thereby confirming that the data 

has indeed been authorised by the holder of the smart 
card 8. 

When a smart card 8 is inserted within a smart card 
reader 7-1; 7-n, access to modules and data stored on the 

30 smart card 8 is effected by the user station 1-1; 1-n to 

which the smart card reader 7-1; 7-n is attached. In this 
embodiment, access to data and program modules provided 
on the card 8 is controlled by the interaction of the 
card interface module 20 and the login module 53. 

35 Together, as will be described, these programs interact 
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to require a user to enter data corresponding to the 
personal identification number 52 stored on the card 8. 
The fact that data corresponding to the pin number 52 has 
been entered is then recorded by the status of the 
5 enabled/disabled flag 58. 

Figure 4 is a flow diagram of the processing of the 
interaction between the card interface module 20 on a 
user station 1-1; 1-n and a login module 53 provided on 
a smart card 8. Initially (S4-1) the card interface 

10 module 20 causes the user station 1-1; 1-n to display to 

a user a request to insert a smart card 8 into the smart 
card reader 7-l;7-n attached to the user station 1-1; 1-n. 

The card interface module 20 then (S4-2) causes the 
user station 1-1; 1-n to determine whether a smart card 

15 8 is presently inserted within the smart card reader 7- 

l;7-n attached to the user station 1-1; 1-n. If this is 
not the case the card interface module 20 causes (S4-1) 
a request that a smart card 8 be inserted into the smart 
card reader 7-l;7-n to be displayed to the user once 

2 0 again before again determining (S4-2) whether a smart 

card 8 has indeed been inserted into the reader 7-l;7-n 
attached to the user station 1-1; 1-n. 

When the card interface module 20 determines that 
a smart card 8 is present within the smart card reader 

25 7-1 ;7-n attached to the user station 1-1; 1-n, the card 

interface module 20 then (S4-3) causes a prompt to be 
displayed to a user to prompt the user to enter a 
personal identification number into the user station 1- 
1 ; 1-n. 

30 When a personal identification number is entered 

into the user station 1-1; 1-n, this is then submitted to 
the login module 53 provided on the card 8 in the smart 
card reader 7-l;7-n attached to the user station 1-1; 1-n, 
which (S4-4) compares the entered identification number 

35 with the personal identification number 52 stored on the 
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smart card 8 . 

If the login module 53 determines that the personal 
identification number received from the user station 1- 
l;l-n does not correspond to the personal identification 
5 number 52 stored on the smart card, the login module 53 

then causes the card interface module 2 0 to redisplay the 
request to input an identification number (S4-3) and when 
a new number is entered and submitted to the login module 
53, the login module 53 rechecks (S4-4) the new 

10 identification number entered by a user. 

If the login module 53 determines that the 
identification number entered by a user into the user 
station l-l;l-n corresponds to the personal 
identification number 52 stored on the smart card 8, the 

15 login module 53 then sets (S4-5) the enabled/disabled 

flag 58 on the smart card 8 to enabled to permit the user 
station 1— l;l-n to access the encryption module 54 on the 
smart card 8 . 

After access to the encryption module 54 on a smart 

2 0 card 8 has been enabled , in this embodiment a user can 

cause the browser program 22 to transmit a session 
request which is transmitted via the Internet 5 to the 
server 3. As will be described in detail later , in 
response to the dispatch of an initial session request, 

25 the server 3 generates a new session identifier which is 

transmitted to the user station l-l;l-n for incorporation 
in subsequent data transactions from the user station 
1-1; 1-n to the server 3. The initial session request 
also causes the server 3 to generate and dispatch data 

30 for generating an initial user interface and a task 

identifier for effecting an initial stage of an 
authorisation procedure which is then processed by the 
browser program 22. 

Figure 5 is a flow diagram of the processing of the 

35 browser program 22 in accordance with this embodiment of 
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the present invention. In this embodiment the browser 
program 22 is invoked whenever a user station l-l;l-n 
receives data for generating a user interface for example 
an HTML script and task identifier from the server 3. 

When the user station l-l;l-n receives data from the 
server 3 via the Internet 5 comprising a task identifier 
and data for generating a user interface, initially (S5- 
1) the task identifier is stored within the memory of the 
user station 1-1. 

The user station l-l;l-n then (S5-2) proceeds to 
generate and display a user interface utilizing the 
received data for generating a user interface such as an 
HTML script in a conventional manner. In this way a user 
interface is displayed to a user into which a user can 
enter data for example name and address data and data 
identifying authorised actions for subsequent storage as 
a user record 40. Alternatively , in the case of some 
data for dispatch when issuing a new smart card 8, for 
example the card identification number 42 or a public key 
55 for public key encryption stored on a new smart card 
8, the user interface would prompt a user to insert the 
smart card 8 being authorised into the card reader 7-7; 7- 
n and access data on the new smart card 8 to obtain 
required data for dispatch. 

When data for dispatch has been obtained utilising 
the user interface the browser program 22 then (S5-3) 
proceeds to generate output data for dispatch back to the 
server 3. Figures 6A, 6B and 6C are schematic block 

diagrams illustrating the generation of data for 
dispatch. In this embodiment initially the browser 
program 22 processes the user inputs, for example text 
data entered into windows or selections made from a menu 
generated from the received HTML script or data obtained 
from a new smart card 8 to generate transaction data 60 
for dispatch as is shown in Figure 6A. 



WO 02/084611 



PCT/GB02/01684 



12 

After the transaction data 60 has been generated, 
the browser program 22 in this embodiment proceeds to 
append to the transaction data 60 a copy of the session 
identifier 62 for the current session between the user 
5 station l-l;l-n and the server 3 which is currently 

stored within the memory of the user station 1-1 , and a 
copy of the task identifier 64 stored within the memory 
of the user station 1-1 , which had previously been 
received together with the latest user interface. The 

10 browser program 20 then appends to the transaction data 

60 , session identifier 62 and task identifier 64 , a copy 
of the card identification data 42 of the smart card 8 
utilised to initiate the access session with the server 
3. Figure 6B illustrates the input data 60 to which the 

15 session identifier , 62 task identifier 64 , and card 

identification data 42 have been appended. 

Having appended the session identifier 62, task 
identifier 64 and card identification data 42 to the 
transaction data 60 for dispatch, the browser program 22 

20 then (S5-4) generates a message hash from the combined 

and appended transaction data 60, session identifier 62, 
task identifier 64 and card identification data 42. This 
message hash is generated in a conventional way which 
generates a code number utilizing the transaction data 

25 60, session identifier 62, task identifier 64 and card 

identification data 42 which is dependent upon the exact 
constitution of the input data 60, session identifier 62, 
task identifier 64 and card identification data 42 so 
that small variations in the data cause substantially 

30 different message hashes to be generated. 

Finally, the browser program 22 then proceeds to 
obtain an encrypted form of this calculated message hash 
by providing the message hash to the encryption module 
54 on the smart card 8 within the reader 7-l;7-n 

35 associated with the user station l-l;l-n. Provided this 
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smart card 8 has been enabled as identified by the 
enabled/disabled flag 58 , this causes encryption module 
54 of the smart card 8 to process the message hash to 
generate an encrypted message hash 66 , utilising the 
5 private key data 56 stored on the smart card 8. This 

encrypted message hash 66 is then appended to the input 
data 60, session identifier 62, task identifier 64 and 
card identification data 42 as is illustrated in Figure 
6C. 

10 The entirety of the transaction data 60, session 

identifier 62, task identifier 64 card identification 
data 42 and encrypted message hash 66 is then dispatched 
to the server 3 via the Internet 5 . 

By incorporating the session identifier 62 and task 

15 identifier 64 within the data dispatched from a user 

station l-l;l-n to the server 3, a means is provided to 
associate each submission of data from a user station 1- 
1 ; 1-n with a particular access session and task made 
during an access session. 

20 By providing a means for generating a message hash 

which is sensitive to amendments of data utilized to 
generate the message hash, it is possible to ensure that 
once the transaction data 60, session identifier 62 task 
identifier 64 and card identification data 42 have been 

25 appended no further amendments occur to the transaction 

data 60, session identifier 62, task identifier 64 or 
card identification data 42 subsequent to the generation 
of the message hash. This is possible because any such 
amendments would cause a different message hash value to 

30 be determined for the amended data. 

Finally, by encrypting the message hash utilizing 
the encryption module 54 and private key data 56 on the 
smart card 8 within the card reader 7-l;7-n associated 
with the user station 1—1; 1-n making the submission, a 

35 means is provided to ensure that the user making the 
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submission is in possession of a valid and authorised 
smart card 8 and that subsequently the submitted data 
cannot be repudiated by the holder of the smart card 8 
as not having originated with the consent of that user. 
5 Thus in this way if the data transmitted via the Internet 

5 is intercepted , it is not possible for the data to be 
amended and then successfully resubmitted to the server 
3. 

Figure 7 is a flow diagram of the processing of the 
10 issuing program 24 in accordance with this embodiment of 

the present invention. The issuing program 24 is invoked 
whenever the server 3 receives data from a user station 
1-1; 1-n via the Internet 5. 

Initially (S7-1) when data is received, the issuing 
15 program 24 causes the server 3 to determine whether the 

received data comprises an initial session request and 
card identification data 42 sent from a user station 1- 
1 ; 1-n. 

If the data received by the server 3 from the 

2 0 Internet 5 comprises an initial session request and card 

identification data 42 , the issuing program 24 then 
(S7-2) causes the server 3 to generate a new task record 
15 comprising a newly generated session identifier 32 
a time stamp 33 being the current time indicated by the 

25 server 3 and an initial task identifier 34. The issuing 

program 24 then dispatches a copy of the session 
identifier 32 and the task identifier 34 together with 
an HTML script for generating an initial user interface 
for entering data for authorising a smart card 8 via the 

30 Internet 5 back to the user station 1-1; 1-n from which 

the session request and the card identification data 42 
had been received. The processing of the issuing program 
2 4 then ends. 

If when data is initially received by the server 3, 

35 the data is determined (S7-1) not to be an initial 
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session set-up request, the issuing program 2 4 then (S7- 
6 ) proceeds to store the data received from the Internet 
5. 

After the received data has been stored , the issuing 
5 program 24 then proceeds to determine (S7-7) whether all 

the data necessary for issuing a smart card 8 has been 
received from the user station 1-1 via the Internet 5. 

In this embodiment this is achieved by the issuing 
program 24 determining whether the database 10 has stored 

10 within it a number of task records 15 having the session 

identifier 32 corresponding to the session identifier 62 
received as part of data received from the Internet 5 
which corresponds to the number of data exchanges 
required to effect the multi-part authorisation required 

15 for issuing a smart card. 

If this is not the case, the issuing program 24 then 
(S7-8) utilises the task identifier 64 of the received 
data to select a user interface corresponding to the next 
task and generates a new task identifier 34 for the next 

2 0 task which is then stored together with the session 

identifier 62 of the received data and a time stamp 33 
indicating the current time as a new task record 15. This 
task identifier 34 is then dispatched together with the 
next user interface for effecting the next stage in the 

2 5 multistage authorisation procedure being effected. The 

processing of the issuing program then ends. 

If after data corresponding to part of an 
authorisation procedure has been received by the server 
3, the issuing program 24 determines (S7-7) that data has 

30 been received for all of the stages of an authorisation 

procedure, the issuing program 24 then (S7-9) determines 
whether all the items of data which have been received 
are valid. 

In this embodiment, the issuing program 2 4 
35 determines whether data received is valid data 



WO 02/084611 



PCT/GB02/01684 



16 

independently for each set of data received via the 
Internet 5. 

Figure 8 is a flow diagram of the processing by the 
issuing program 24 to determine the validity of received 
5 data. The processing of Figure 8 occurs in relation to 

each set of data constituting part of a multi-part 
authorisation procedure . 

Initially (S8-1), in this embodiment, the issuing 
program determines whether any of the task records 15 

10 stored in the database 10 include a time stamp 34 

indicating a time older than a default value, for example 
15 minutes. If this is the case, the server 3 assumes 
that the session for which the task record 15 was 
generated has been interrupted and therefore the server 

15 3 proceeds to delete all the task records 15 including 

the session identifier 32 corresponding to the session 
identifier 32 of the task record 15 having an out of date 
time stamp 34. Thus, in this way the issuing program 22 
ensures that the database 10 is periodically purged of 

20 unused task records 15 and also the security of the 

system is increased as each session is limited in 
duration unless authorisations are regularly completed. 

The issuing program 24 then (S8-2) causes the server 
3 for each item of stored received data including a 

25 session identifier 62 corresponding to the session 

identifier 62 of the most recently received set of data 
to determine whether the session identifier 62 and task 
identifier 64 of each set of received data corresponds 
to the session identifier 32 and task identifier 34 of 

30 a task record 15 stored within the database 10. If this 

is the case, the task record 15 including the session 
identifier 32 and task identifier 34 is then deleted from 
the database 10. 

The issuing program 24 then (S8-3) determines 

35 whether the message hash data 66 included within each 
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stored data set is valid. In this embodiment, this is 
determined by the server 3 initially decrypting the 
encrypted message hash 66 of the stored data set 
utilising the public key 44 of a user record 17 
5 incorporating the card identification data 42 

corresponding to the card identification data 42 included 
within the received set of data. The server 3 then 
proceeds to generate a message hash from the stored 
transaction data 60, session identifier 62 , task 

10 identifier 64 and card identification data 42 in the same 

way which has previously been described in relation to 
the processing by the browser program 22. The data 
generated by decrypting the encrypted message hash 66 and 
the generated new message hash from the other data within 

15 the data set are then compared. If these are identical , 

this indicates that the received set of data was also 
used to generate the message hash encrypted utilising 
the private key 56 on the smart card 8 identified by the 
card identification data 42 in the data set and that none 

20 of the data within the other data set has been amended 

after dispatch from the user station 1-1; 1-n. 

Finally , after the validity of the task identifier 
64 and session identifier 62 in the received data set has 
been confirmed and the message hash checked , the issuing 

25 program 24 then (S8-4) determines whether the 

authorisation data 64 within the user record 40 
incorporating the card identification data 42 
corresponding to the card identification data 42 in the 
received data set includes data identifying the user of 

30 that card as being authorised to issue a new smart card. 

If this is the case, the server 3 records (S8-5) that the 
data set under consideration is correctly authorised. 

If , however, either the task identifier 62 or task 
identifier 64 are not determined to be valid or the 

35 message hash 66 is determined not to be correct or the 
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authorisations 64 for a user are insufficient, the server 
3 records the data set as unauthorised (S8-6). This 
process is then repeated for each of the subsequent data 
sets received for all the stages of the authorisation, 
5 Returning to Figure 7 , after the validity of each 

of the data sets involved in a multi-stage authorisation 
process have been determined , the issuing program 24 then 
(S7-10) determines whether the entire transaction for 
generating a new user record 17 , and thereby authorising 

10 a new smart card 8, is authorised. If this is the case, 

the server 3 then (S7-11) proceeds to generate a new user 
record 17 comprising a card identification number 42, 
public key data 44, authorisation data 46 and user 
details 4 8 from the received transaction data 60 whose 

15 validity had been confirmed. 

Although in the above embodiment an authorisation 
procedure . has been described in which steps in an 
authorisation procedure are performed sequentially, the 
present invention is particularly applicable to systems 

20 in which stages of an authorisation procedure can be 

effected in any order. A second embodiment will now be 
described in which the order of stages in an 
authorisation procedure may be varied. 
Second Embodiment 

25 In this embodiment of the present invention the 

hardware provided corresponds to the hardware in the 
first embodiment as shown in Figure 1 and description of 
the hardware will not be repeated here. However, the 
processing by the browser program 22 and issuing program 

30 2 4 is amended to enable the user to vary the order in 

which tasks in a multi-stage authorisation process are 
performed. 

Figure 9 is a flow diagram of the processing of a 
user station 1-1; 1-n in accordance with this embodiment 
35 of the present invention. Initially (S9-1) the browser 
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program 22 of the user station l-l;l-n is utilized to 
access the server 3 via the Internet 5 in a conventional 
manner. As a result of a connection being established 
between the user station 1-1; 1-n and the server 3 the 
5 server 3 dispatches a session identifier 32 and task 

identifier 34 to the user station 1-1 together with a 
user interface to effect a login request. 

When the session identifier 32 and task identifier 
34 are received and stored within the memory of the user 

10 station 1-1 the browser program 22 then utilizes the 

received login user interface to initiate a card login 
procedure (S9-2) similar to the card login procedure 
previously described with reference to Figure 4. 

After a user has completed the card login procedure 

15 and is therefore able to pass data from the user station 

1-1; 1-n to the encryption module 54 of a smart card 8- 
l;8-m inserted within the reader 7-1 ; 7-n attached to the 
user station 1-1; 1-n, a user is prompted to identify 
which task they wish to perform by selecting the task 

20 from the user interface generated by the browser 22 from 

the data received from the server 3. When a task has 
been selected the browser program 22 then dispatches 
transaction data 60 comprising the new task request 
together with a copy of the session identifier 32 and 

25 task identifier 34 , a card identification number 42 and 

an encrypted message hash 66 in a similar way as has been 
described in the previous embodiment. 

This data is then received and processed by the 
server 3 which in response dispatches a new task 

30 identifier 34 and an initial user interface for the 

selected task to the user station 1— l;l-n making the new 
task request. When (S9-4) this new task identifier and 
initial user interface are received by the user station 
1-1; 1-n, the new task identifier 34 is stored within the 

35 memory of the user station 1-1; 1-n and the initial user 
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interface for the selected task is displayed to a user. 

In this embodiment, each of the user interfaces 
dispatched by the server 3 via the Internet 5 to a user 
station l-l;l-n comprise user interfaces enabling a user 
5 to either select a new task, end an access session or 

enter data for effecting an authorisation procedure as 
part of a task being undertaken. If a user selects to 
perform a new task on the user interface (S9-5) this 
causes the user station 1-1 to dispatch transaction data 

10 60 comprising a request for the new task together with 

the session identifier 32 and task identifier 34 
currently stored within the memory of the user station 
l-l;l-n together with a card identifier 42 and an 
encrypted message hash 66 the same way as has previously 

15 been described to the server 3 via the Internet 5. In 

response to receiving such data the server 3 outputs a 
new task identifier 34 and initial user interface for the 
newly selected task and data identifying the step in a 
process the user interface is to be utilized to effect. 

20 These are received by the user station l-l;l-n and 

processed in a similar way in which the initial user 
interface received following the login procedure is 
processed (S9-4). 

If utilizing the user interface displayed on the 

25 user station l-l;l-n a user selects to end a session (S9- 

6) the processing of the browser program 22 finishes. 

If the user does not select a new task to be 
initiated (S9-5) and the user does not make a selection 
to end the current session (S9-6) but instead (S9-7) the 

30 user enters data utilizing the currently displayed user 

interface when data has been entered to effect a portion 
of a task this is then dispatched as transaction data 60 
together with a copy of the session identifier 62 and 
task identifier 64 currently in memory, card 

35 identification data 42 and an encrypted message hash 66 
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in the same way as has been described in relation to the 
first embodiment* Additionally, in this embodiment the 
browser 22 also dispatches data identifying the step in 
a process the transaction data 60 represents. 
5 In response to receiving transaction data 60 the 

server 3 then outputs the next user interface to effect 
the next stage in the currently selected authorisation 
process. When this is received (S9-8) it is displayed 
by the user station l-l;l-n the user can again either 

10 select to initiate a new task (S9-5) select to end the 

current session (S9-6) or enter further data to be 
transmitted as transaction data (S9-7). 

Thus in this way by linking some stages in an 
authorisation procedure as part of the same task for 

15 example data entry and the witnessing/authorisation of 

that data entry where such steps must occur in the 
specified order the processing of an authorisation 
* procedure in this way ensures that the order in which 
these steps take place is maintained. 

20 However, by dividing other parts of an authorisation 

procedure, for example, separate authorisation/witnessing 
steps between different tasks and enabling a user to 
select which task is to be performed a flexible work flow 
can be achieved . 

25 Figure 10 is a flow diagram of the processing of an 

issuing program 24 on a server 3 in accordance with this 
embodiment of the present invention. As in the previous 
embodiment the issuing program 2 4 is initiated whenever 
the server 3 receives data from the internet 5 . 

30 Initially, when data is received (S10-1) the issuing 

program 24 determines whether the data received comprises 
a new session request. If this is the case the server 
then (S10-2) proceeds to generate a task record 15 in a 
similar manner that is described in the first embodiment 

35 and dispatch a copy of the session identifier 32 and task 
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identifier 34 of the newly generated task record 15 back 
to the user station l-l;l-n from which a session request 
has been received together with a user interface for 
effecting a card login request. The processing of the 
5 issuing program 25 then ends. 

If , the issuing program 24 determines that received 
data does not correspond to a new session request the 
issuing program 24 then (SI 0-3) determines whether the 
transaction data 60 received comprises a request to 

10 initiate a new task. If this is the case the issuing 

program 2 4 then (S10-4) generates a new task record 
comprising a new task identifier 34 and the session 
identifier 32 corresponding to the session identifier 62 
received together with the new task request in the same 

15 manner in which the task record has been described as 

being generated in the previous embodiment. The issuing 
program 2 4 then dispatches a copy of the task identifier 
34 of the newly generated task record 15 together with 
an initial user interface for the requested task. The 

20 processing of the issuing program 24 then ends. 

If the issuing program 24 determines that 
transaction data 60 received from the Internet 5 
comprises neither a new session request nor a new task 
request , the issuing program 2 4 then (SI 0-5) determines 

25 whether the transaction data 60 included within the data 

received from the Internet 5 comprises an instruction 
that the data necessary to effect a task has been 
received and that the received data should now be 
processed. If this is not the case the issuing program 

30 24 then stores the received transaction data 60, session 

identifier 62 , task identifier 64, card identification 
data 42 and encrypted message hash 6 6 and then dispatches 
the next user interface for inputting data to effect the 
next stage in the task selected utilizing the data 

35 identifying the step the received transaction data 60 is 
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intended to represent. The processing of the issuing 
program 24 then ends. 

If, however, the issuing program 24 determines that 
the transaction data 60 received comprises an instruction 
5 that all of the data necessary to effect an authorisation 

procedure has been received and that a task is therefore 
complete the issuing program then (S10-7) proceeds to 
determine whether the received transaction data 60 
necessary to effect the authorisation procedure is indeed 

10 valid and that the transaction is therefore authorised 

(S10-8) and if so update the user record accordingly 
(S10-9) in a similar way in which the validity of 
received transaction data is determined as has been 
described in the first embodiment. However, in this 

15 embodiment the deletion of the task records 15 including 

task identifiers 34 corresponding to a task identifier 
64 inn stored received data occurs only after the 
validity of all of the stored data for effecting a task 
in an authorisation procedure has been checked. This is 

20 because in this embodiment, a single task record 15 is 

generated for each task in a procedure rather than for 
each data submission as was described in the first 
embodiment. After any authorised updates of the user 
records 17 have occurred, the processing and the issuing 

25 program 24 then ends. 

Amendments and Modifications 

Although the present invention has been described 
in relation to systems for issuing smart cards, it will 

30 be appreciated that it is also applicable to other on- 

line systems, for example e-commerce systems in which 
multiple data sets are transmitted via the Internet. The 
present invention is also applicable to networks other 
than the Internet such as internal Intranets or other 

35 communications systems such as telephony systems. 
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Although in the above embodiments systems have been 
described which data transmitted from a user station 1- 
l;l-n is transmitted in an unencrypted form, it will be 
appreciated that in other embodiments for additional 
security prior to dispatch via the Internet 5, the 
browser program 22 could be arranged to encrypt all the 
data being sent to the server 3 and the server 3 could 
be arranged to decrypt any data received from the 
Internet 5* 

Although in the above embodiments , the checking of 
time stamps 33 is described as occurring whenever a task 
is to be validated , it will be appreciated that deletion 
of time expired task records 15 could occur periodically 
instead. 

Although in the above embodiments , task records 15 
and user records 17 have been described as both being 
stored on a database 10 separate from the server 3, the 
database 10 could be arranged only to store the user 
records 17 with task records being stored on the server 
3 . An advantage of such an arrangement would be that 
access to the database 10 would be limited to determining 
whether transactions were authorised. The amount of data 
traffic between the server 3 and database 10 would 
therefore be reduced and the security of the database 10 
enhanced. 

Although the above embodiments have been described 
with reference to public /private key encryption systems 
and smart cards 8 r any suitable encryption schemes could 
be utilized. For example , encryption schemes based on 
passwords could be used. 

Alternatively, instead of utilising a smart card 8 
and smart card reader 7-1; 1-n, encryption using a 
separate hand held encryption device could be used. In 
such a system message hash data would be generated by a 
user station 1-1; 1-n and displayed to a user. The 



WO 02/084611 



PCT/GB02/01684 



25 

displayed message hash data, would then be entered into 
the separate encryption device which would process the 
data to generate encrypted data which would then be 
displayed to a user to enable the user to enter the data 
5 into the user station 1-1; 1-n for inclusion in data 

dispatched to a server. In such a system no direct 
communication occurs between the user station 1-1; 1-n and 
the encryption device and hence security is increased. 

Also, although confirmation of the validity of a 

10 database submission has been described in terms of 

decrypting an encrypted messages hash, it will be 
appreciated that confirmation could be achieved by a 
server repeating the message hash generation and 
encryption process performed at a user station 1-1; 1-n 

15 and comparison of this encrypted message hash with 

received encrypted message hash could occur. 

Alternatively, instead of encrypting only the 
message hash the entirety of the transaction data, 
session identifier, task identifier and message hash 

20 could be encrypted. Upon receipt decryption of the 

combined data could occur based upon a decryption method 
selected utilizing received card identification data and 
then the validity of the message hash could be confirmed 
to ensure the received encrypted data had not been 

25 amended. 

Although the embodiments of the invention described 
with reference to the drawings comprise computer 
apparatus and processes performed in computer apparatus, 
the invention also extends to computer programs , 

30 particularly computer programs on or in a carrier, 

adapted for putting the invention into practice. The 
program may be in the form of source or object code or 
in any other form suitable for use in the implementation 
of the processes according to the invention. The carrier 

35 be any entity or device capable of carrying the program. 

For example, the carrier may comprise a storage 
medium, such as a ROM, for example a CD ROM or a 
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semiconductor ROM, or a magnetic recording medium, for 
example a floppy disc or hard disk. Further, the carrier 
may be a transmissible carrier such as an electrical or 
optical signal which may be conveyed via electrical or 
5 optical cable or by radio or other means. 

When a program is embodied in a signal which may be 
conveyed directly by a cable or other device or means, 
the carrier may be constituted by such cable or other 
device or means . 

10 Alternatively, the carrier may be an integrated 

circuit in which the program is embedded, the integrated 
circuit being adapted for performing, or for use in the 
performance of, the relevant processes. 



15 
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CLAIMS : 

1 • A method of confirming the validity of a plurality 
of items of transaction data transmitted from a remote 
5 station to a server across an open communications 

network, said method comprising the steps of: 

at said server, storing a task identifier and 
dispatching a copy of said task identifier to said remote 
station; 

10 at said remote station, for each of said items of 

transaction data, generating signature data by encryption 
of a said item of transaction data combined with said 
task identifier and dispatching a data set comprising 
said encrypted signature data, said item of transaction 

15 data and identification data to said server; and 

at said server, receiving said dispatched data sets, 
and for each received data set, selecting an encryption 
method on the basis of identification data in said data 
set, and determining the validity of an item of 

20 transaction data in said data set by utilising said 

selected encryption method to determine whether received 
encrypted signature data in said data set corresponds to 
data generated from combined data incorporating said 
stored task identifier. 

25 

2. A method in accordance with claim 1, wherein said 
determining step comprises the steps of: 

utilizing said selected encryption method to decrypt 
said signature data; and 
30 identifying whether decrypted signature data 

corresponds to data obtained from processing combined 
data comprising said item of transaction data and said 
task identifier. 



35 



3. A method in accordance with claim 2, wherein said 
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generation of signature data comprises the steps of: 

generating message hash data by processing a said 
item of transaction data combined with said task 
identifier in accordance with a message hash generation 
method; and 

encrypting said generated message hash data; and 
wherein said identifying step comprises the steps 

of : 

generating further message hash data by processing 
a said received item of transaction data combined with 
said task identifier in accordance with said message hash 
generation method and comparing said further message hash 
data with said decrypted signature data. 

4. A method in accordance with claim 2, wherein said 
generation of signature data comprises encrypting said 
transaction data combined with said task identifier. 

5. A method in accordance with claim 1, wherein said 
determining step comprises the steps of: 

utilizing said selected encryption method to 
generate further signature data by processing combined 
data comprising a said item of transaction data and a 
said task identifier in a received data set; and 

identifying whether said further signature data 
corresponds to said signature data in said received data 
set . 

6. A method in accordance with claim 5, wherein said 
generation of signature data comprises the steps of: 

generating message hash data by processing a said 
item of transaction data combined with said task 
identifier in accordance with a message hash generation 
method; and 

encrypting said generated message hash data; and 
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wherein said generation of further signature data 
comprises the steps of: 

generating further message hash data by processing 
a said item of transaction data combined with a said task 
5 identifier in a received data set in accordance with said 

message hash generation method and encrypting said 
further message hash data utilizing said selected 
encryption method. 

10 7. A method in accordance with claim 1 , wherein said 

encryption of a said item of transaction data combined 
with said task identifier comprises encrypting said 
combined data utilizing a data processing device 
accessible by said remote station. 

15 

8. A method in accordance with claim 7, wherein said 
data processing device comprises a smart card. 

9. A method in accordance with any of claim 1, wherein 
20 said encryption of a said item of transaction data 

combined with said task identifier comprises the steps 
of : 

providing a separate encryption device; 
inputting data representative of said item of 
25 transaction data and said task identifier into said 

encryption device ; 

utilising said encryption device to encrypt said 
input data and display encrypted data; and 

inputting displayed encrypted data into said remote 
30 station. 

10. A method in accordance with claim 1, wherein said 
storing step comprises storing a task identifier in 
association with time stamp data indicative of a time of 

35 storage and wherein said determining step comprises 
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determining whether time stamp data associated with a 
task identifier associated with received transaction data 
is indicative of a time of storage greater than a 
predetermined time period before receipt of said received 
transaction data. 

11. A method in accordance with claim 1, further 
comprising the step of: 

at said server, in response to receiving at least 
some of said data sets, storing a task identifier and 
dispatching a copy of said task identifier to said remote 
station; 

wherein said remote station generates signature data 
utilizing the most recently dispatched task identifier. 

12. A method in accordance with claim 11, further 
comprising the step of: 

dispatching with said copy of said task identifier 
means for generating user interface means at said remote 
station; and 

utilizing said user interface means to generate an 
item transaction data for dispatch to said server* 

13. A method in accordance with claim 1, wherein said 
task identifier comprises a first portion and a second 
portion wherein said first portion comprises fixed data 
and said second portion comprises variable data. 

14. A method in accordance with claim 1, further 
comprising the step of: 

if a said received data set is determined to be 
valid, utilizing said transaction data. 

15. A method in accordance with claim 13, said 
utilisation of said transaction data comprises generating 
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or modifying a record in a database. 

16. A method in accordance with claim 1, wherein said 
transaction data comprises data indicative of a smart 

5 card authorisation. 

17. A server for confirming the validity of a plurality 
of items of transaction data to be utilized in a process, 
said server comprising: 

10 a data store able to store task identification data 

associated with steps in a process to be performed, prior 

to performance of said process; 

a receiver for receiving a plurality of data sets, 

each of said data sets comprising encrypted signature 
15 data, an item of transaction data and identification 

data; 

a selector operable to select an encryption method 
on the basis of identification data in a data set 
received by said receiver; and 

20 a validator operable to determine the validity of 

a plurality of items of transaction data from a plurality 
of data sets received by said receiver to be utilized in 
a process to be performed , wherein said validator is 
operable to determine the validity of said data by 

25 utilising encryption methods selected by said selector 

to determine for items of transaction data in each data 
set, whether encrypted signature data in a said data set 
received by said receiver corresponds to data generated 
from combined data incorporating task identification data 

30 stored in said data store associated with respective 

steps in a process to be performed. 



35 



18. A server in accordance with claim 17, wherein said 
validator comprises : 

a decryptor operable to decrypt signature data in 
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a data set received by said receiver utilising an 
encryption method selected by said selector for 
identification data in said data set; and 

a correspondence determinator operable to determine 
5 whether decrypted signature data corresponds to data 

obtained from processing combined data comprising an item 
of transaction data in said data set including said 
signature data and task identification data for a step 
in a process to be performed stored in said data store. 

10 

19 . A server in accordance with claim 18 , wherein said 
validator further comprises a message hash generator 
operable to generate message hash data by processing an 
item of transaction data in a received data set combined 

15 with task identification data associated with a step in 

a process to be performed stored in said data store, 
wherein said comparator is operable to compare said 
generated message hash data with decrypted signature data 
decrypted by said decryptor. 

20 

20. A server in accordance with claim 17 , wherein said 
validator comprises : 

a signature generator operable to process combined 
data comprising an item of transaction data and task 
25 identification data in a data set received by said 

receiver; and 

a comparator operable to compare signature data 
generated by said generator with signature data in said 
data set received by said receiver. 

30 

21. A server in accordance with claim 20 , wherein said 
signature data generator comprises: 

a message hash generator operable to generate 
message hash data by processing an item of transaction 
35 data in a data set received by said receiver combined 
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with task identification data in said received data set; 
and 

an encryptor operable to encrypt said message hash 
data utilising said encryption methods selected by said 
5 selector. 



22. A server in accordance with claim 17, wherein said 
data store is operable to store said task identification 
data in association with time stamp data indicative of 

10 a time of storage, and wherein said validator is operable 

to determine the validity of an item of transaction data 
in a data set received by said receiver by determining 
whether time stamp data associated with a task identifier 
within a data set received by said receiver including 

15 said item of transaction data is indicative of a time of 

storage greater than a predetermined time period before 
receipt of said received data set. 

23. A server in accordance with claim 17, further 
2 0 comprising a task identification data dispatcher for 

dispatching a copy of a task identification data for a 
step in a process to be performed stored in said data 
store r upon receipt of the data set for a previous step 
in said process by said receiver. 

25 

24. A server in accordance with claim 2 3 , wherein said 
dispatcher is further operable to dispatch data for 
generating a user interface for inputting items of 
transaction data for a subsequent step in said process. 

30 

25. A server in accordance with claim 17, wherein said 
data store is operable to store task identification data 
for steps in a process comprising a first portion and a 
second portion wherein said first portion comprises the 

35 same data for all steps in said process and said second 
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portion comprises variable data. 

26. A server in accordance with claim 17 , further 
comprising a processor for processing received items of 
transaction data to perform a said process associated 
with task identification and by said data store, if said 
items of transaction data have been determined by said 
validator to be valid. 

27. A server in accordance with claim 2 6 , wherein said 
processor is operable to process said transaction data 
to generate or modify a record in a database. 

28. A server in accordance with claim 17, wherein said 
items of transaction data received by said receiver 
comprises data indicative of the smart card 
authorisation . 

29. A computer for dispatching a plurality of data sets 
comprising transaction data for performing a process on 
a server, said computer comprising: 

a receiver for receiving task identification data 
associated with steps in said process to be performed on 
said server; 

a signature data generator operable for each of a 
plurality of items of transaction data to generate 
signature data by encryption of a said item of 
transaction data combined with said task identification 
data received by said receiver; and 

a dispatcher operable to dispatch for each item of 
transaction data a data set comprising encrypted 
signature data encrypted by said signature data 
generator, said item of transaction data and 
identification data . 
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30. A computer in accordance with claim 29 , wherein said 
signature data generator comprises: 

a message hash generator operable to process an item 
of transaction data combined with task identification 
5 data received by said receiver; and 

an encryptor operable to encrypt said generated 
message hash data. 

31. A computer in accordance with claim 2 9 , wherein said 
L0 signature data generator comprises an encryptor operable 

to encrypt an item of transaction data combined with a 
task identifier received by said receiver. 

32 . A data carrier storing computer implementable 
L5 process steps for generating within a programmable 

computer a server in accordance with any of claims 17 to 
28. 

33. A data carrier storing computer implementable 
2 0 process steps for generating within a programmable 

computer, a computer in accordance with any of claims 2 9 
to 31 . 

34. A data carrier in accordance with claim 32 or 33 r 
25 comprising a computer disc. 

35. A data carrier in accordance with claim 32 or 33 , 
comprising an electric signal transferred via the 
Internet . 

30 

36. A computer disc in accordance with claim 34 , wherein 
said computer disc comprises an optical, magneto-optical 
or magnetic disc . 
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